技術 [Day 21]：客服機器人為什麼要拒絕回答「今天天氣如何」？談 Off-topic Guardrails

捷運客服拒絕回答「今天天氣如何」，可以是一個合理的產品選擇。前提是服務範圍已經說清楚，而且遇到「颱風會影響營運嗎」時，仍能辨認出應該受理的需求。 這兩句話都沒有...

技術 [Day 12]：能用規則 (Rule) 判斷的事情，就不要先叫 LLM

在 Day 10 的文章裡，筆者把合成資料的品質檢查拆成三層：先看資料結構，再用確定性規則核對已知條件，最後才把難以直接寫成規則的問題交給語意判斷。 讀者可能會...

技術 [Day 8]：不要叫模型一次生成：合成 PII 測試資料時拆成可追蹤的階段任務（Stage）

昨天 Day 7 的文章先把一筆 Guardrails 測試案例寫成種子資料（Seed Contract），分清楚哪些條件要固定、哪些內容可以變化，以及哪些資訊...

技術 [Day 7]：先別寫 Prompt：先設計出資料種子(Data Seeding)來定義案例、邊界與資料分布

上一篇先把 Guardrails 的六個驗收情境改寫成合成資料需求，並且分清楚三類條件：哪些一定要固定、哪些可以變化、哪些不能交給模型自行發明。 接下來很容易直...

技術 [Day 5]：Guardrail 有擋到就算驗收？把企業政策 (Policy) 變成可以一直重跑的測試、實踐 Policy As Code

筆者在 Day 4的文章裡談到，企業為什麼不能只要求 Guardrail「接得上」或「能跑得動就好」。 當企業今天用了 A Guardrail，半年後可能換成...

技術 [Day 4]：手搓 Guardrail 不難，企業真正難題怎麼把它管起來

筆者在 Day 3 的文章中把「不要洩漏個資」這句要求，拆成三件事： 系統要檢查什麼 照什麼規則判斷 發現問題後要怎麼處理 如果今天只有一個客服系統、一個模...